The Internet success is the result of the IP architecture's robustness, flexibility, and ability to scale, and NOT on its efficiency, optimization, security, fine-grained control or performance guarantees. Furthermore, TCP/IP data networks are still suffering from some basic (quite inherent) problems, such as, denial of service attacks and unstable throughput.
1. Field and Context of the Invention
The field of the invention is assuring trusted operation which is guaranteed and validated by the underlying methods and systems. In particular assuring trusted flow of communications, and more specifically, making sure that the end stations and users of a computer network operate correctly under a given and known rules of transmissions, even though protocols, methods and software logic is typically available to users of such networks. Trusted operation means an operation which performance complies with its allowed and defined specifications.
This will assure network elements that stations perform their task as known and as determined by a service agreement. It will assure servers in networks that users are behaving properly and are not over using resources beyond the allocated and allowed parameters. The mechanisms involve signaling and allow piggybacking of proper signals for various purposes, e.g., authentication of stations and users. The mechanisms involve communication network software, communication network operation, control and management. They further involve cryptographic systems and functions and software transformation such as obfuscation operation. They involve computing hardware and software systems.
In general, the underlying mechanisms assure that a “combined functionality” is taken place at a computing system, part of this “combined functionality” is a crucial function of the underlying computing system whereas some other part of this “combined functionality” is a method to generate an unpredictable signal. The mechanisms make sure to interlock the parts into the combined functionality. The locking means that all parts must be performed. The operation part, which is factored into the “combined functionality” is trusted (and is typically associated with limitations such as rate of operation or number of times before renewal of precondition for next sub-operation). The checking is done merely by being able to check the signal. If the signal passes the check, it means that the other (operation) part was performed as well (thus, it was performed subject to the associated limitation, namely as a trusted one).
The operation involves a trusted flow of packets (or other units of communication fields), the flow is associated with rules of transmission. For example, a TCP connection is associated with a window size that allows maximum number of transmissions. A trusted flow implies that the end station conforms to the allocated window size. However, there is no way to impose on users and end stations to comply with the assumed parameters, and be “trusted” since typically parameters can be easily changed.
The novel idea behind our mechanisms is the “interlocking” of parts and insisting that one part will “signal” and its checking will assure compliance, by adding a checking function to validate signals. Thus if a TCP program with the currently correct performance parameters (i.e., rules of transmission) is interlocked with a cryptographic pseudo-random generator (with a random seed), which output cannot be predicted, and if further the checker has a copy of the pseudo-random generator, then if further the output of the pseudo random generator is put on data packet headers, then if the headers are checked and their content matches the expected value from the generator, the checker concludes that the packet flow is “trusted.”
The basic mechanism involves a system where the “combined functionality” is performed and one where it is checked. It also involves a communication system. It involves a software transformation module to assure the interlocking of the separate functions into a combined functionality, finally a management system assuming plurality of elements implementing the combined functionality is in the network.
2. Background of the: Prior Art
In traditional telephone networks the user of the telephone device cannot over burden the network with signals beyond the allocated circuit it gets. On the other hand, in software operations and thus in computer communication networks, a user gets access to the software in its station, the same software which is in charge of regulating the user himself. As a results users can “control” the network rather than the network controlling the users.
Indeed, it is assumed that there is availability of logic (i.e., software) of methods for controlling communication and for preparation of data packets for transmissions. The description is given in numerous books: “Computer Networks” (3rd Edition) by A. Tannebaum, Prentice Hall, 1996; “Internetworking with TCP/IP” by D. E. Corner, Prentice-Hall, Third Edition, 1995, ISBN 0-13-216987-8, and “TCP/IP Illustrated, Vol. 1: The Protocols” by W. R. Stevens, Addison-Wesley, Reading, Mass. 1994.
Known in the art, are methods to try to detect users' misbehavior and to react to them. Firewalls, intrusion detection methods, data packet filtering, connection dropping are methods to react to user over flooding the network, they are “reactive”. See the following references: “Building Internet Firewalls” (2nd Edition) by Elizabeth D. Zwicky, Simon Cooper, D. Brent Chapman, Deborah Russell; Publisher: O'Reilly & Associates; ISBN: 1565928717; 2nd edition (Jan. 15, 2000). “Internet Security: Professional Reference” by Derek Atkins (Editor), Paul Buis, Chris Hare, Robert Kelley, Carey Nachenberg; New Riders Publishing; ASIN: 1562055577; Bk&Cd-Rom edition (February 1996).
Mechanisms for the avoidance of misbehavior by having a user and end station use a trusted software and signal that they use it to a checker are not known in the art. We are not aware of a method that further assures that the user cannot replace the trusted software while continue to signal correctly. We are not aware of means to identify “trusted flows” as a unique and separate stream of communication, which may deserve a better class of service, though class of service are known in the art and are used differently. Such a method allows one to assure that trusted flows continue to be transmitted while using traditional reactive methods against the non trusted flow.
Our methods use cryptographic functions such as pseudo random generation, random bits generation, authentication, signature, and encryption. Such methods of varied level of security and efficiency are known in the art, in software packages and in hardware devices. We can employ them as needed in our mechanisms. We do not assume any invention of any of the underlying cryptographic technique employed at different steps and different mechanisms herein. A security professional familiar with the art, will be able to use the cryptographic functions and tools and embed them in our invention. Such mechanism are described in “Applied Cryptography: Protocols, Algorithms, and Source Code in C,” 2nd Edition by Bruce Schneier; Publisher: John Wiley & Sons; ISBN: 0471117099; 2 edition (Oct. 18, 1995) and in “Handbook of Applied Cryptography” (CRC Press Series on Discrete Mathematics and Its Applications) by Alfred J. Menezes, Paul C. Van Oorschot, Scott A. Vanstone (Editor); Publisher: CRC Press; ISBN: 0849385237; (October 1996).
Same is true for underlying devices, we can employ such devices as smart cards and other portable devices (USB connection based, wireless devices with radio frequency, laser connection, etc.)—a security engineer familiar with the art and the common practice will be able to employ these elements and embed them in our invention.
The method uses hidden programs. One method to hide programs is software obfuscation transformations. Methods and techniques for obfuscation are also known in the art. They modify the “look” of the software logic, but maintain its “semantics” (or meaning). They are analogous to compiling a program in high level language code to a program in “object code” or “machine code” which performs the same task but is not readable to most of users. They make the software “unreadable” and “non-modifiable”. We do not invent any underlying basic code obfuscation methods. In fact there are various methods in the art applied to the currently most useful programming languages. The methods take a software program (say in Java language) and return another program (in Java as well) which performs the same task and approximately with the same performance. Yet, the second program is hard to read and understand. The art of program obfuscation, including all transformations on data, variables, names, control structure, etc. are given in a number of papers considered the state of the art by C. Collberg C. Thomborson and D. Low: “Manufacturing Cheap, Resilient and Stealthy Opaque Constructs,” ACM's POPL 1998, pages 184-196; and “Watermarking, Tamper-Proofing, and Obfuscation-Tools for Software Protection,” by Collberg, Thomberson and Low, technical report University of Arizona to be published in IEEE Transactions on Software Engineering 2002; and “A Taxonomy of Obfuscation Transformation,” by C. Collberg, technical report number 148, University of Arizona.
Additionally, Valdez and Yung describe how to add encryption operation and program distribution to obfuscation in: “Software DisEngineering: Program Hiding Architecture and Experiments,” by E. Valdez and M. Yung, Information Hiding 1999, pages 379-394, Springer Verlag Lectures in Computer Science; and “SISSECT: DIStribution for SECurity Tool,” by E. Valdez and M. Yung, ISC 2001, pages 125-143, 2001 Springer Verlag Lectures in Computer Science LNCS2200, respectively. Note that the embedding of programs inside tamper proof devices and hiding encrypted programs are also known in the art (e.g., as part of cryptographic co-processors). In our mechanism we use a combination of the above techniques
Note that hidden programs have been traditionally employed to hide the logic of the software. They have been used in hiding cryptographic programs (e.g., in a tamper proof device) so that the operation is not observable or modifiable. They have been further used to enforce certain operation associated with content distribution and electronic commerce, assuring that such notions like digital payment and protecting of content are run in an environment that is not modifiable by the user. Again, the notion of use is against modification of the working environment.
Unlike the use of hiding and obfuscation of programs for the sake of software protection, the current invention does not hide the “semantics of the program” from the user. In fact, the specification and performance parameters can be publicly known—the goal is, in turn, an integrity function, where the goal is for users not to be able to change the operation software (that performs data packet transmission) while retaining correct signaling.
What is needed is a mechanism that combines many programs together so that they are inseparable. In this sense, hidden programs are merely a means to get a method of “interlocking mechanism” where known (rather than unknown) programs and perhaps hidden parameters (hidden) are combined into a unique functionality and are inseparable. The interlocking involves putting together a set of “well behaved” programs with correct and agreed upon parameters with a continuous mechanism for signaling, and associating the signaling checker with a method that assures good behavior of the continuous flow. What is new is that we involve system programs, which are commonly known, programs that perform packet generation and performance parameters and even known cryptographic programs with hidden parameters. What is needed in our invention is not a method of hiding the logic, and its semantics, but a method where it is impossible via hidden programs to execute parts of the combined functionality separately with a malicious non-trusted part replacing another part of the combined functionality.
What are also needed are a mechanism for checking component for the signals, as well as a combined communication system mechanism for handling the trusted flow coming from station that use the combined functionality. This will give network elements that can assure trusted traffic is generated in a trusted fashion and further is validated. Also needed methods and systems employing the elements above in a combined network and that will manage, renew and tune the elements in the invention. Method for dynamically change hidden program and parameters and for renewing preconditions are needed as well. Finally, what is needed is a method for generating and distributing the combined functionality logic modules, a mechanism for safe integration of separate known logic modules to the combined functionality logic.